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ABSTRACT 


This  paper  presents  an  architecture  for  a generalized  model  management 
system  that  facilitates  the  integration  of  management  science  models  into 
a decision  support  system.  The  objective  of  the  system  is  to  support  the 
decision-maker  both  in  specifying  a problem  and  in  effecting  a solution. 
This  is  accomplished  by  providing  him/her  with  a means  for  interacting 
with  a complex  structured  database  to  specify  the  structure  of  some 
problem;  and  to  solve  the  model  defined  for  the  problem  using  appropriate 
information  — either  from  the  database  or  some  other  source  — and 
efficient  solution  procedures. 
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MODEL  MANAGEMENT  SYSTEMS: 

A FRAMEWORK  FOR  DEVELOPMENT 


Joyce  J.  Elam 


1.0  INTRODUCTION 

This  paper  presents  a general  frameworK  for  the 
development  of  a model  management  system  ( MKS ) that 
facilitates  the  use  of  mathematical  models  and  techniQues  by 
a decision-maker  in  an  interactive  problem  solving 
environment.  The  objective  of  the  system  is  to  support  the 
decision-maker  both  in  specifying  a problem  and  in  effecting 
a solution.  This  is  accomplished  by  providing  him/her  with 
a means  for  interacting  with  a complex  structured  database 
to  construct  a model  of  some  problem,  to  find,  if  available, 
a previously  developed  monel  for  the  problem,  and  to  solve 
the  model  defined  for  the  problem  using  appropriate 
information--  either  from  the  database  or  some  other 
source--  ana  efficient  solution  procedures. 

The  phii sopny  which  underlies  the  design  of  this  system 
j-s  (1)  models,  like  data,  are  an  organizational  resource  and 
can  be  described,  executed,  and  manipulated  by  some 
generalized  software  system  and  (2)  a general  framework  can 
oe  designed  for  managing  a variety  of  model  types 
(optimization,  suo-optimization  (heuristics),  statistical, 
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simulation,  descriptive,  etc.).  by  viewing  models  in  an 
analogously  way  as  data,  much  of  the  recent  research  in 
database  management  systems  can  applied  to  tnis  research. 


2.0  NEED  FOR  RESEARCH 

The  proolems  facing  today's  decision-maker  - both  in 
the  private  and  public  sectors  - are  highly  complex,  are 
continually  changing  — both  as  a result  of  a dynamic 
environment  or  a changed  perception  of  the  problem--  and 
require  immediate  solutions  that  have  far-reaching 
implications.  In  addition,  the  data  that  impacts  on 
solutions  to  these  problems  is  voluminous,  dynamic,  and  may 
originate  from  many  different  sources.  The  complexity  of 
these  problems  has  necessitated  the  use  of  mathematical 
models  and  efficient  data  management  capaoilities  to 
organize  the  voluminous  amounts  of  data  into  useful 
information . 

Lata  management  capabilities  have  been  greatly  enhanced 
with  the  development  of  database  management  systems.  Much 
research  has  focused  on  efficient  ways  to  create,  access, 
and  maintain  the  large  collection  of  data  of  an 
organization.  A major  advantage  of  database  management 
systems  is  that  the  physical  storage  details  are  transparent 
to  the  users  or  procedures  that  require  access  to  the 
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Optimization  algorithms  ana  mathematical  methoas  such 
as  linear  programming,  networx  analysis,  simple  and  multiple 
regression,  exponential  smoothing,  Monte  Carlo  simulation, 
etc.  have  been  the  subject  of  intensive  research  during  tne 
last  few  years.  As  a result,  the  cost  of  solving  various 
models  has  dropped  significantly.  It  is  now  computationally 
feasible  for  organizations  to  use  these  techniques  in 
supporting  their  decision-making. 

Although  considerable  research  has  been  directed  toward 
database  technology  and  management  science  independently, 
little  researcn  has  been  airected  towara  integrating  tne  two 
technologies.  This  is  evidenced  by  currently  available 
modeling  systems  such  as  TROLL  [hiATUl]  and  TSP  LhALOl]  which 
have  good  analytical  capabilities  but  poor  data  management 
capabilities  and  SYSTEM  2uU0  [wRIOl],  SEED  [iwTOI],  and  IMS 
[IBM01]  which  provide  gooa  data  management  capabilities  but 
poor  analytical  capabilities.  iiataoase  management  systems 
have  not  been  designed  with  the  goal  of  supporting 
analytical  techniques.  Correspondingly,  analytical  systems 
have  assumed  that  the  data  to  be  analyzed  preexists  in  some 
standard  form  and  have  not  addressed  the  problems  associated 
with  structuring  the  aata  in  the  proper  format. 

The  lack  of  integration  has  resulted  in  the  following: 

1 . Current  database  management  systems  are  used  in 
applications  aimed  at  operational  control  or 
management  control  in  organizations.  The  major 
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concerns  of  such  systems  are  with  the  raw  data  of 
an  organization.  In  general,  current  systems  do 
not  have  the  capabilities  to  support  higher-level 
decision  making. 

2.  Mathematical  techniques  are  not  being  efficiently 
used.  An  extremely  important  aspect  for  the 
implementation,  use,  and  acceptance  of  a 
mathematical  model  is  its  informational 
requirements  and  accesibility . Too  often  it  is 
difficult  if  not  impossible  to  extract  the  data 
needed  for  an  analysis  trom  the  organizational  data 
base.  tven  if  the  aata  is  obtained,  it  is  up  to 
the  user  to  reformat  the  aata  to  conform  to  the 
data  requirements  of  the  analytical  software  system 
to  be  used. 


The  major  impact  of  management  science  has  been  on 
structured  problems  where  the  decision-maker  can  oe  provided 
with  detailed  recommendation  for  handling  these  problems 
[K.EEG1],  Expanding  the  use  of  management  science  techniques 
for  supporting  the  decision-making  required  by  less 
structured  problems  requires  a more  extensive  involvement  of 
the  decision-maker.  The  MMS  will  facilitate  this 


involvement . 
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3.0  MODEL  MANAGEMENT  SYSTEMS : WHAT  CURRENTLY  EXISTS 

Tnere  nave  been  attempts  over  the  past  several  years  to 
automate  the  ouilaing  ana  processing  of  computer-Dasea 
information  systems.  This  section  will  briefly  review  this 
research  and  summarize  those  aspects  that  relate  to  tne 
development  of  a generalized  MMS . 

The  ISDOS  project  developed  by  Xeichroew  and  others 
[TEI01]  at  the  University  of  Michigan  provides 
computer-aided  techniques  for  defining,  recording,  and 
analyzing  functional  requirements  for  information  processing 
systems.  The  ultimate  ODject  of  the  ISDOS  project  is  to 
produce  executable  software  for  a particular  computing 
environment  directly  from  a set  of  functional  requirements. 
ISDOS  contains  two  major  components:  PSL  (Problem  Statement 
Language)  --  a formal  language  for  expressing  in  a 
structured  form  the  major  components  and  relationships  that 
exist  in  a system  that  is  to  be  computerized  and  PSA 
(Problem  Statement  Analyzer)  --  a software  system  tnat 
analyzes  the  requirements  specified  in  the  PSL  and  attempts 
to  construct  software  modules  and  databases  in  accordance 
with  tnese  requirements  and  some  stated  performance 
criteria.  The  concept  of  a PSL  has  direct  implications  for 
the  model  definition  language  used  in  the  MMS  in  that  the 
MMS  should  have  a language  for  specifying  the  general 
characteristics  of  a model  independent  of  the  specific 
programming  language  that  is  eventually  used  to  represent 
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the  problem  in  a structured  form  suitable  for  analysis. 

Interactive  planning  systems  have  teen  developed  for 
representing  ana  manipulating  models  and  aata  tnat  relate  to 
financial  planning  problems.  These  systems  include  BPL 
L INT02]  , FORESIGHT  [FGRG1],  PLATO  [IBM02],  IPSY  [INT03]  and 
others  [S0P01].  In  general,  these  systems  have  the 
xoliowing  capabilities:  (1)  a particular  modeling  language 
for  specifying  the  structure  of  tne  problem  facea  Dy  the 
planner  (2)  r epor t -gener at  ion  routines  for  allowing  reports 
to  be  tailor-made  by  the  user  and  (3)  various  analysis 
capabilities  that  can  be  defined  by  the  moaeling  language  or 
can  be  defined  at  execution  time  [hiiROI].  These  systems 
facilitate  user  interaction  in  tne  planning  activity  but 
provide  no  general  moael  management  functions.  Few  systems 
have  the  capability  to  interface  with  the  operational  aata 
of  the  organization  of  interest  even  though  the  data  used  by 
~he  planning  system  tends  to  be  a specialized  processed 
version  of  the  operational  data  of  tne  organization. 

Other  software  systems  falling  under  the  general 
category  of  decision  support  systems  proviae  some  model 
management  functions.  The  GPLAN  system  developed  by 
khinston  and  other  at  Purdue  [NUN01]  for  supporting  a 
decision-maker  in  water  quality  management  incorporates  (1) 
a library  of  application  models  and  (2)  an  English-like 
mapping  language  for  automatically  interfacing  data  with 
models.  The  GADS  system  LmAmOIJ  developea  by  IBM  to  aid  the 
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city  of  San  Jose  police  department  in  the  assignment  of 
police  beats  facilitates  person-machine  interaction  both  in 
constructing  a solution  to  the  problem  and  in  presenting 
various  solutions  to  the  decision-maker.  However,  it  does 
no t permit  easy  access  to  data  either  by  the  decision-maker 
or  the  solution  process  that  is  constructed.  The  system 
recently  deveoped  by  Donovan  and  others  [D0N01]  at  MIT  for 
nationwide  energy  planning  information  system  provides  for 
generalized  interfaces  between  software  systems  but  no 
facilities  for  model  definition.  No  system  incorporates  a 
lull  range  of  model  managememt  functions.  This  is  not 
unexpected  since  each  system  is  specialized  for  a particular 
application  and  for  a particular  class  of  users. 

The  most  recent  relevant  work  in  model  management  is 
the  interactive  modeling  system  developed  by  Katz  and  Miller 
[KAT01]  to  aid  decision-makers  in  accessing  the  relative 
benefits  and  costs  of  alternative  mitigation  and  recovery 
policies  for  natural  hazards.  l'nis  system  is  composed  of 
three  subsystems:  tne  model  subsystem,  the  analysis 
subsystem,  and  the  library  subsystem.  The  model  subsystem 
applies  a set  of  processing  subroutines  to  an  input  file  of 
victim  records  in  order  to  calculate  some  additional 
attribute  value(s)  for  each  record.  The  output  of  this 
stage  is  a file  oi  expanded  victim  records.  The  analysis 
subsystem  performs  aggregation,  summarization,  statistical 
analysis,  etc.  on  a file  of  victim  records  created  by  the 
modeling  subsystem.  The  library  subsystem  manages  the 
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libraries  of  subroutines  available  to  users  in  the  model  and 
analysis  subsystems.  Each  of  these  systems  is  invoked  Dy  a 
separate  person-computer  interface.  By  means  of  these 
interfaces,  user  interaction  with  the  system  is  facilitated. 
The  main  limitations  of  this  system  can  be  summarized  as 
follows : 

1 . A variety  of  model  types  cannot  be  defined 

2.  Although  this  is  one  of  the  few  systems  tnat 
contain  a library  function,  it  is  rather  limited  in 
scope  . 

3.  The  system  does  not  interlace  directly  with  some 
generalized  data  base. 

This  system  does,  however,  contain  some  unique  features  for 
facilitating  interactions  with  users,  for  integrating  new 
processing  subroutines  into  the  subsystems,  and  for  linking 
data  values  with  the  processing  subroutines.  Many  of  tne 
ideas  set  forth  in  this  paper  for  a generalized  model 
management  system  are  drawn  from  tnis  work. 

The  DAISY  system  [HUR02,  MOROI]  developed  at  the 
bniversity  of  Pennsylvania  strives  to  aid  the  decision-maker 
in  his/her  decision  process  Dy  providing  easy  access  to 
programs,  data,  and  models  that  are  available  anc  relate  to 
some  general  decision  problem.  Although  some  research  has 
been  directed  toward  interfacing  models  with  data  [hITOI], 
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no  general  model  management  capabilities  are  available.  The 
MMS  specified  in  this  paper  can  be  integrated  within  tne 
DAISY  f raieworK,  drawing  on  tne  other  existing  components  of 
DAISY  when  necessary.  In  a like  manner,  a general  MMS  could 
be  incorporated  into  any  of  the  specialized  systems  listed 
above  . 


4.0  FRAMEWORK  FOR  DESIGN 

4.1  Introduction 

A computer-based  information  system  can  be  viewed  as 
consisting  of  four  major  software  components  [JOhOI]: 


Figure  1 

The  communicator  is  responsible  for  facilitating  interchange 
between  a user  and  the  information  system;  the  Report 
Generator,  for  providing  system-generated  information  in 
us e r - sp ec i f i ed  form  ; the  Dataoase  Management  System,  for 
retrieving  ana  storing  information;  the  Model  Management 
System  (MMS),  for  all  other  processing  in  the  system.  Each 
process  under  control  of  the  MM S will  be  refer1  red  to  as  a 
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model . 

The  MMS  thus  forms  the  kernel  of  computer-basea 
information  system.  The  remainder  of  this  paper  focuses  on 
its  design  and  its  interaction  witn  the  other  components. 


4.2  Objectives 

Effective  model  management  encompasses  all  phases  of 
model  activity  --  construction,  testing,  execution, 
validation  and  maintenance  --  and  facilitates  the  use  of 
models  that  are  simple,  roDust,  easy  to  control,  adaptive, 
complete  on  important  issues,  and  easy  to  communicate  with 
[LITG1].  The  following  general  objectives  for  the  MMS  are 
formulated  within  this  context. 

1 . The  MMS  snould  provide  ooth  formal  and  informal 
descriptions  of  a model  and  the  assumptions  that 
went  into  constructing  it. 

2.  Model  description  snoulc  be  separated  from  mouel 
execution . 

3.  The  execution  of  a model  (the  joining  of  a model 
process  witn  its  information  requirements)  should 
be  automatic . 

4.  The  MMS  should  provide  information  on  what  types  of 
models  exist  anu  for  what  purposes. 
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5.  The  MMS  shoula  be  an  active  system  in  tnat  it  (1) 
alerts  user  when  model  assumptions  are  violated  and 
(2)  provides  alerts  concerning  model  validity. 

o.  The  MMS  snould  allow  a model  to  be  changed  easily. 

7.  The  MMS  should  provide  information  on  model  useage, 
cost,  security. 


4.3  Architecture 

An  overview  of  the  architecture  proposed  for  the  MMS  is 
depicted  in  Figure  2.  Tne  three  components  of  this 
architecture  --  users,  functional  modules,  and  data  --  are 
detailed  oelow. 

4.3*1  Users  - 

The  users  who  interface  with  the  MMS  can  be  divided 
into  four  classes:  the  model  user,  the  model  ouilder,  the 
model  implementor  and  the  model  administrator.  These  users 
are  involved  with  different  pnases  of  the  modeling  activiy 
and  interact  with  the  MMS  at  different  levels.  A similar 
classification  of  users  was  proposed  by  Katz  and  Miller 
LKATO 1 ] . 


Users 


Functional 

Modules 


Data 

Requirements 


Data  Dictionary 
Database 
(Operational/ 
Model-based) 

Model-Base 
Solution  Files 
Interface  Files 


Model  Management 
Architecture 


System 


Figure 
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I'ne  model  user  interacts  with  the  MMS  at  a high  level 
to  find  and  execute  previously  developed  monels  . The  model 
user  through  the  Communicator  issues  commands  to  initiate 
model  execution  and  responds  to  any  prompts  for  data.  The 
MMS  automatically  performs  model  execution  and  presents  the 
results  as  specified  by  the  user.  The  model  user  is 
typcially  a non-programmer  who  requires  minimal  knowledge  of 
the  system. 

The  model  builder  interacts  with  the  MMS  to  construct 
models.  The  model  builder  is  supplied  with  commands  for 
data  collection,  data  analysis,  and  model  assembly.  The 
model  builder  is  a more  sophisticated  user  tnan  a model  user 
and  requires  a more  thorough  knowledge  of  the  system.  This 
user  does  not,  however,  need  to  be  a computer  programmer. 

The  moael  implementor  interacts  with  the  Mhs  to  provide 
the  interfaces  between  model  definition,  data  requirements, 
and  model  processing  programs  that  are  necessary  to  support 
automatic  model  execution  and  validation.  The  model 
implementor  may  also  provide  the  computer  programs  necessary 
for  model  processing  (These  may  also  be  supplied  from  other 
sources.).  The  model  implementor  interacts  at  a low  level 
with  the  MMS  and  requires  computer  programming  and 
analytical  skills. 

The  model  administrator  nas  overall  responsibility  for 
the  MMS.  he/sne  ensures  that  the  MMS  objectives  are  met  in 


the  most  efficient  manner. 


The  model  administrator  is 
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involved  witn  model  debugging,  testing,  validation, 
documentation,  accounting  and  access. 


4.5*2  Functional  Modules  - 

The  MhS  is  divided  into  four  major  components:  Model 
Development,  Model  Processing,  Model  Administration,  Model 
Interlace  . The  functions  contained  in  each  component  are 
detailed  below. 


4.3.2. 1 Model  Development  - 

The  oasic  functions  of  the  model  development  component 
are  to  (1)  support  interactive  model  building  and  (2)  to 
provide  information  about  previously  defined  models  to  users 
and  to  the  other  components  of  the  MhS. 

The  process  of  model  building  involves  data  collection, 
data  analysis,  and  model  assembly.  Le  assume  that  the  data 
to  be  collected  is  contained  in  tne  operational  database  of 
the  organization  or  in  a special  model-related  database. 
The  model  building  subsystem  must  contain  a query  language 
for  easily  accessing  this  data.  These  languages  are 
available  in  many  database  managment  systems  [ INTO  1 ,MRI0 1 ] 
and  can  easily  be  interfaced  witn  the  model  building 
subsystem.  The  major  focus  of  the  model  building  subsystem 
will  be  on  model  assembly.  [Data  analysis  can  be  viewed  in 
the  same  manner  as  any  mouel  which  is  built,  executed,  ano 
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analyzed  tnrough  the  MhS  and  data  collection  is  supported  oy 
the  Database  Management  System.] 

A basic  concept  underlying  the  design  cf  tne  MMS  is 
that  the  description  ot  a mooel  is  separated  from  its  actual 
physical  realization.  The  decision-maker  who  builds  a model 
of  some  decision  process  (i.e.,  the  model  builder)  should 
have  a language  for  expressing  this  model  in  informal, 
English-like  terms.  A general  design  for  a model 
description  language  (MDL)  is  shown  in  Figure  3.  Using  this 
language,  a model  is  cnaracterizeu  by  a set  of  entities,  a 
set  of  relationsnips  oe tween  these  entities,  and  a set  of 
assumptions  upon  which  these  relationsnips  are  based.  The 
entities  and  relationships  are  described  by  a set  of 
attributes  that  are  defined  as  being  either  controllable  or 
uncontrollable.  At  any  instance  of  time,  particular  data 
values  can  be  associated  with  each  attribute.  The  data 
values  associated  with  controllable  attributes  are  (1)  user 
supplied  (2)  data-Dase  supplied  or  (3)  model-supplied  (i.e., 
the  result  of  some  previous  model  process).  The  data  values 
associated  with  uncontrollable  attriDutes  are  determined  by 
applying  a model  processing  program  to  the  model 
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MODEL  NAME : 

ENTITY  NAME: 

ATTRIBUTE  NAME: 

TYPE: < CO NT ROLL ABLE , UN  CON TROLL ABLE > 
SOURCE : <Database , User,  MoueI> 
SELECTION  CRITERIA: 


RELATIONSHIP  NAME: 

ENTITIES  INVOLVED: 

ATTRIBUTE  NAmE: 

TYPE: <CON TROLL ABLE , U N CON TROLL ABLE > 
SOURCE : <Database , User,  Moael> 
SELECTION  CRITERIA: 


MODEL  TYPE: 

MODEL  SOLUTION: 

MODEL  INTERFACE: 

VERSION : 

DATE : 

KEYWORDS : 

MODEL  ASSUMPTIONS : NAME : <Assumption  Name) : predicate 


Figure  3 


definition.  These  data  values  are  stored  in  the  data  base, 
reported  to  the  user,  ana/or  supplied  as  input  to  another 
model.  The  remaining  information  provided  by  the  mDL 
supports  other  mouel  management  functions  to  oe  discussed 
subsequently.  The  model  building  subsystem  contains 
software  to  process  the  model  definition  as  expressed  in  the 
MdL  . Using  an  available  data  dictionary  and  the 
organizational  database  (operational  and  moaei-based ) , this 
software  creates  a model-base.  The  moael-base  is  the 
primary  means  for  logically  linking  data  to  the  model 


definition . 
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Another  major  function  include  a within  model 
aevelopment  is  the  model  dictionary.  The  moaei  dictionary 
subsytem  supports  users  in  determining  what  types  of  models 
exist  and  for  what  purposes.  It  also  provides  information 
on  the  types  of  model  processing  programs  (solution 
procedures)  that  are  availaoie  and  their  informational 
requirements.  The  model  dictionary  subsystem  interacts  with 
two  basic  types  of  data:  the  model-Dase  and  the  interface 
files.  The  interface  tiles  contain  information  on  solution 
procedures  and  will  be  discussed  more  tnoroughly  in  model 
processing.  Using  this  aata,  the  model  dictionary  subsystem 
can  provide  the  following  information: 

1.  The  input  and  output  specifications  for  each  set  of 
model  processing  programs  (solution  procedures) 
managed  by  the  MMS . 

2.  The  useage  of  specified  data  items  in  modei 
descriptions  . 

3.  Model  assumptions. 

4.  Models  that  relate  to  specific  applications. 

3.  Solution  procedures  tnat  are  available  for  various 
model  types  . 

b.  Model  descriptions. 
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4 . 3 • 2 . 2 Moael  Processing  - 

As  explained  in  Pioael  Development,  data  values  can  be 
associated  with  the  attributes  that  define  some  model. 
Model  processing  involves  the  physical  linking  of  data 
values  to  these  attributes.  The  linking  of  data  values  to 
controllable  attributes  is  referred  to  as  creating  a model 
instance.  The  linking  of  a model  instance  to  a solution 
procedure  is  referred  to  as  model  execution.  The  linking  of 
data  values  to  uncontrollable  attributes  is  referred  to  as 
model  solution.  Model  processing  will  perform  this  linking 
in  much  the  same  manner  as  proposed  in  [KAT01].  The  system 
will  do  what  linking  it  can  automatically  and  will  leave  the 
rest  to  the  user. 

Model  processing  interacts  with  four  basic  types  of 

data:  the  database,  the  model-base,  interface  files  and 

solution  procedure  files.  To  create  a model  instance,  tne 

model  execution  subsystem  uses  the  database,  mooel-base,  and 

user-supplied  data.  If  the  source  of  any  controllaole 

% 

attribute  is  a moael  process,  a submodel  instance  is  created 
and  processed  in  order  to  obtain  tne  appropriate  data 
values.  The  linking  of  a model  instance  to  a solution 
procedure  is  accomplisned  through  the  use  of  interface 
files.  The  interface  files  contain  information  on  input  and 
output  requirements  of  a solution  procedure.  Many  different 
models  that  are  defined  may  use  the  same  solution  procedure, 
by  associating  a general  interlace  file  with  each  solution 
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procedure , the  automatic  linkage  of  data  to  model  processing 
programs  is  facilitated.  It  is  expected,  however,  that  some 
interaction  between  the  user  and  tne  system  will  be 
necessary  to  perform  linkages  when  using  a general  interface 
file.  In  addition  to  general  interface  files,  specialized 
interface  files  can  be  constructed  for  a particular  model 
and  solution  procedure  that  would  minimize  the  need  for  user 
interaction  in  executing  tne  model.  This  would  be  desirable 
for  frequently  executed  models.  Once  a model  has  been 
processed  (i.e.,  pnysically  linked  to  a solution  procedure) 
it  can  be  solved  either  in  batch  or  interactive  mode. 

Once  a model  has  been  solved,  the  results  can  be 
presented  to  a user,  stored  in  the  aataDase,  or  used  in 
another  process.  The  hoael  Processing  System  again 
interacts  with  the  model-base,  data-base,  interface  files, 
and  user  profile  files  to  output  the  results  in  the 
appropriate  way.  The  user-profile  files  contain  information 
on  the  format  of  output  desireci  by  each  individual  user. 
The  Model  Processing  component  also  will  interact  with  the 
Report  Generator  to  present  the  results  of  model  solution  in 
a specified  form. 


4.3.3  Model  Administration 
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Model  Administration  is  concerned  with  model  validation 
and  model  maintenance.  The  model  validation  subsystem  is 
responsible  for  monitoring  the  model  assumptions  and 
informing  a user  when  the  assumptions  are  violated  during 
model  proce ssing . The  model  assumptions  can  be  specified  in  a 
similar  manner  as  integrity  constraints  in  database 
management  systems  [DAT01J.  The  model  validation  system 
should  also  provide  tne  capabilities  for  replicatively 
validating  a model  - matching  the  model-generated  data  with 
data  already  available  in  the  database  - and  for 
predictively  validating  a model  - matcning  the 
model-generated  data  with  data  to  be  stored  in  the  dataoase 
at  some  future  point. 

The  model  maintenance  sub  system  provides  software  to 
modify  model  descriptions,  monitor  access  to  models,  provide 
back-up,  and  create  and  maintain  user  profile  files, 
interface  files,  and  solution  iiles. 


4.3-4  Model  Interface  - 

The  MMS  is  a command-driven  system.  The  Model 
Interface  analyzes  commands  for  various  mocel-management 
functions  supplied  by  the  user  tnrough  the  Communicator  and 
invokes  the  appropriate  suosystem  for  performing  that 
command.  The  basic  commands  to  be  supported  correspond  to 
the  modeling  activities  of  development,  processing,  and 
administration.  A sample  list  of  commands  is  shown  in 
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Admini- 

stration 


BACK 


Provide  Back-up 


NEW 


Add  new  file 


MODIFY 


modify  existing  file 


USEAGE 


Provide  information 
on  useage  of  models 


DELETE 


Delete  file 


Figure  4 


5.0  CONCLUSIONS 

The  purpose  of  this  paper  has  been  to  outline  the 
architecture  for  a generalized  model  management  system  that 
facilitates  the  integration  of  management  science  models 
into  a decision  support  system.  The  MMS  provides  support 
for  the  modeling  activity  through  Model  Development,  Model 
Processing  and  Model  Administration.  Through  model 
development,  a decision-maxer  can  formulate  a model  of  some 
decision  process  and  relate  this  model  to  other  operating 
models  within  the  system.  Model  processing  provides  a 
high-level  mechanism  for  interfacing  data,  models  and 
solution  procedures  so  that  the  user  is  relieved  of 
low-level  data  management  functions.  Model  administration 
allows  the  collection  of  models  to  be  treated  as  an 
organizational  resource  and  managed  accordingly.  The  MMS 
provides  a general  frameworx  for  incorporating  into  a 
decision  process  the  use  of  any  type  of  formal  model. 
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Figure  4 . 


Related  MMS  Function 

Command  function 

Building  FIND 

Provide  Access  to 
Database 

BUILD 

Using  MDL  specify 
model  structure 

CHANGE 

Modify  structure 

ADD 

Expand  structure 

SUBTRACT 

Delete  all  (or  part)  of 
structure 

Dictionary  ShON 

Display  model 
descriptions,  names,  etc 

FIND 

Find  models  relating 
to  specific 
applications 

HOW 

Display  how  a 
particular  model 
is  solved 

Processing  CREATE 

Create  a model  instance 

PROCESS/USING 

Process  a model  using 
a specified  inter- 
face file 

RUN /USING 

Solve  a model  using  a 
specified  solution 

procedure 

STORE 

Store  results  of  model 

Output  LIST/USING 

Create  a user 
report  using  a 
specified  user  profile 
and  interface  file 

Verifi-  MONITOR 

cation 

Check  Assumptions 

VALID ATE /BY 


Specify  vali- 
dation procedure 


